With the emergence of 3G mobile telephony, new packet-based communication technologies using IP (Internet Protocol) have been developed to support wireless communication of multimedia. For example, communication protocols in GPRS (General Packet Radio Service) and WCDMA (Wideband Code Division Multiple Access) support packet-switched multimedia services, as well as traditional circuit-switched voice calls.
A network architecture called “IP Multimedia Subsystem” (IMS) has been developed by the 3rd Generation Partnership Project (3GPP) as a platform for handling multimedia services and sessions in the packet domain, based on IP transport. Thus, an IMS network can be used to initiate and control multimedia sessions for IP enabled terminals being connected to any type of access networks. A signalling protocol called “SIP” (Session Initiation Protocol, according to the standard IETF RFC 3261) has been defined for handling sessions in IMS networks. A “SIP-enabled” terminal can thus use this standard to initiate and terminate multimedia communications by means of its home IMS network.
FIG. 1 is a simplified schematic illustration of a basic network structure for providing multimedia services for a mobile terminal A by means of an IMS network 100. The terminal A is connected to a mobile access network 102 and communicates in a multimedia session with another terminal B which may be connected to the same access network 102 or another access network (not shown). Alternatively, terminal A may communicate with a content server or the like, e.g. for downloading some multimedia content therefrom.
The access network 102 is connected to IMS network 100 which is the “home” IMS network of terminal A and therefore handles the session with respect to terminal A. The same IMS network 100 or another one (not shown), may handle the session on behalf of terminal B. Moreover, multimedia services are always handled by the terminal's home IMS network even if terminal A would be roaming in a visited access network.
The session is controlled by specific nodes in the IMS network 100, here generally referred to as “session managing nodes” 104. These nodes include S-CSCF (Serving Call Session Control Function), I-CSCF (Interrogating Call Session Control Function) and P-CSCF (Proxy Call Session Control Function, according to the conventional IMS architecture. Briefly described, a P-CSCF node acts as an entry point towards the IMS network 102 from access networks, including network 100, a plurality of S-CSCF nodes are assigned to active terminals for managing their sessions using SIP signalling, and an I-CSCF node acts as a gateway for SIP messages from other IMS networks.
The IMS network 102 also includes one or more application servers 106 for enabling various multimedia services, and a main database element HSS (Home Subscriber Server) 108 containing subscriber and authentication data. The various functions of the shown network elements 104-108 are generally known in the art, and not necessary to describe here further to understand the context of the present invention. Of course, IMS network 102 contains various other nodes and functions not shown here for the sake of simplicity. In the figure, the thick two-way arrow illustrates the communication of payload data between the two terminals A, B. The thin two-way arrow illustrates the communication of control messages, typically according to SIP in the case of IMS.
A policy unit 110 associated with the access network 102 is also connected to the IMS network 100. The policy unit 110 is basically responsible for authorizing communication sessions for terminals connected to the access network 102, based on various predetermined policies and rules. The policy unit 110 generally operates according to a function implemented therein called PCRF (Policy and Charging Rule Function), sometimes alternatively referred to as PDF (Policy Decision Function).
The PCRF uses a rule engine that evaluates session information related to a requested session, in order to determine whether the session can be allowed or not. A session may be allowed conditionally, e.g., “session X is allowed if condition Y is met”. Session admission rules defined in the rule engine of policy unit 110 specify when to allow sessions for specific users and/or services. The rules can be combined into policies which may be defined for specific users or services, or both. When a session request is received from a user for a specific service, a relevant policy or rule combination is thus selected and evaluated for the session request for allowance or rejection.
Many mobile applications and services require a certain Quality of Service QoS in order to provide a satisfying and expected result to end-users. For UMTS networks, four main traffic classes have been defined: “conversational class”, “streaming class”, “interactive class” and “background class”, in order to classify different needs and requirements regarding bit rates and delays. These traffic classes are primarily distinguished by their requirements regarding transfer delays, such that applications of the conversational class tolerate only small delays, sometimes also referred to as “real-time”, whereas the background class is applied to the least delay-sensitive applications, sometimes also referred to as “best effort”.
The selection of a UMTS traffic class for an application is used for assigning a suitable physical channel in the mobile network, generally referred to as a RAB (Radio Access Bearer), in order to optimise the scarce radio recourses and other transport resources in the radio access and core networks whilst maintaining an acceptable and expected level of quality for the end-user.
Another factor that may dictate the QoS requirements is the subscription type. Thus, subscribers may be offered specific service levels with respect to QoS for different subscription types. For example, using current terms, a “Platinum” subscription may be defined to guarantee a relatively high level of service or QoS, whereas “Gold”, “Silver” and “Bronze” subscriptions may provide successively lower levels of service or QoS. Moreover, specific services may also be offered with different levels of QoS, e.g. at different prices.
FIG. 2 illustrates a conventional process when a mobile terminal A will communicate multimedia with another party B, involving different stages 2:1-2:9 as illustrated. Here, each stage may generally represent the communication of various messages and/or data back and forth which are not necessary to describe in more detail.
IMS nodes P-CSCF 202 and S-CSCF 204 are shown here in a schematic “control plane” for control signalling over the IMS network. Further, a gateway node GW 200 in the core part of a mobile network, typically a GGSN (Gateway GPRS Switching Node), is shown in a schematic “bearer plane” used for the data transport. The gateway node GW 200 is connected to an associated policy unit 206, here denoted PCRF, which is thus basically responsible for authorizing communication sessions to terminals in the associated mobile network, as described above. In some systems, a so-called “Policy and Charging Enforcement Function” (PCEF) in the GGSN node typically communicates with the PCRF node over a Gx interface to control the access admission, and the PCRF node communicates with the P-CSCF node over an Rx interface.
In a first stage 2:1 of the illustrated procedure, terminal A obtains an initial connection with the mobile network, typically involving the activation of a PDP context and a Radio Access Bearer RAB, as established by the gateway node GW 200. A particular PCRF 206 is also selected for terminal A by GW 200 at this point. The established access bearer is primarily used for carrying occasional control messages of minor size such as service requests, allowing for relatively low bandwidth and fairly long delays.
In a next stage 2:2, GW 200 sends relevant access information to PCRF 206, including a subscription identifier and the bearer information established in stage 2:1. Thereby, a “state” is created in PCRF 206 for a “bearer session”, meaning that the received access information for terminal A is retained in PCRF 206. In this stage, PCRF 206 also responds to GW 200 by sending a so-called “basic charging rule” that has been selected or created based on the received access information. The basic charging rule includes a charging key, a charging identity and any service data flow filters that should be applied on communicated data according to that rule. A certain basic level of QoS, typically the “best effort” level, has now also been established for non-IMS data services such as the communication of various control messages as mentioned above.
When a user activates a selected application in terminal A in order to communicate with terminal B in this case, an SIP-based user agent (“SIP UA”) in terminal A performs a session negotiation in a following stage 2:3, which may involve the exchange of terminal capabilities with terminal B. In the session negotiation, terminal A may start by sending an SIP INVITE message as a session request towards terminal B containing session-specific parameters typically including a proposed coder/decoder (or “codec”) for the session.
After the session negotiation, as the session parameters have been settled, the P-CSCF node 202 sends corresponding service information to PCRF 206, in a next stage 2:4. Thereby, another state is created in PCRF 206 for a “service session”, meaning that the received service information for the session of terminal A is retained in PCRF 206. Moreover, PCRF 206 determines whether the requested session should be allowed or not by applying a suitable policy.
If PCRF 206 can allow the requested session according to the applied policy for the given user and service, an OK message is sent to the P-CSCF node 202 which also sends an OK message to the terminal A, in a stage 2:5. The application activated in terminal A then requests a bearer from a bearer part in terminal A, in a following stage 2:6, in order to satisfy QoS requirements for communication according to the application. Terminal A then issues a bearer request for service data transport to GW 200 in the mobile network, in a next stage 2:7. Alternatively, the establishment of bearer may also be initiated by the mobile network.
In a further stage 2:8, GW 200 now establishes a new bearer for the forthcoming data transport, as required by the service, and sends relevant QoS information on the established service bearer to PCRF 206 where the bearer session state is updated accordingly. In this stage, PCRF 206 also responds to GW 200 by sending an updated charging rule based on the received service and QoS information. The updated charging rule includes a service identity, a charging identity and any service data flow filters according to that rule. Hence, a certain level of QoS has also been established for the requested service, typically a higher QoS level than the one established for non-IMS data services in stage 2:2 above.
The above-mentioned basic charging rule and updated charging rule established for terminal A in stages 2:2 and 2:8, respectively, are often referred to as “PCC (Policy and Charging Control) rules”, in effect being rules for session admission. In general, a PCC rule is used for detecting packets belonging to a service data flow, identifying the service, and for providing relevant charging parameters and policy control for a data flow. A PCC rule may be predefined or created dynamically, and includes basically a rule name, a service identifier, service data flow filters, QoS parameters and charging parameters.
Finally, terminal A can start the session involving the communication of data between the two terminals A and B, as illustrated by a final step 2:9. The new service bearer or RAB established in stage 2:8 should be more stable and reliable than the access bearer established for control messages in stage 2:2, to provide a “guaranteed” level of QoS according to the service involved as controlled by the updated charging rule. As mentioned above, different levels of QoS may also be expected depending on the subscription and/or selected level of service.
However, the mobile network will undoubtedly sometimes fail to fulfil the agreed level of QoS during such sessions. The reasons for not providing the agreed levels of service can be many, often depending on the current traffic situation such as cell congestion and interference problems, but also on factors related to the operation of the network such as inadequate power regulation, equipment failure, inaccurate channel allocation and poor radio coverage, etc.
Today, there is no efficient way to monitor service level agreements in mobile networks, and consequently it cannot be controlled that these agreements are met properly. Hence, if a customer complains that an expected QoS level has not been fulfilled during a session, the network operator has no means to check the relevance thereof. Moreover, the operator cannot work proactively to ensure that service level agreements are fulfilled. Instead, a reactive process must be used for investigating a network in order to identify such problems and where they typically occur. This is an expensive and time consuming activity that nonetheless must be undertaken in order to improve the fulfillment of service agreements, and to avoid customer dissatisfaction and the paying of resulting penalty fees.